The Light Weight Directory Access Protocol (LDAP) has become very popular due to its efficient and fast data access. A large number of applications/services are currently in use and being developed which use an LDAP directory as their centralized data repository.
The LDAP directory stores entries as a tree. Each entry may consist of one or more attribute names and attribute values. An entry may be uniquely identified by its distinguished name (DN) that may include a common name (cn) attribute of the entry and DN of a parent entry.
The contents of the entries are governed by an LDAP directory schema. The schema defines object classes and each entry has an objectClass attribute containing named classes defined in the schema. The objectClass attribute may be multivalued and contain the class “top” as well as some number of other classes. The schema definition for each class an entry belongs to defines what kind of object the entry may represent (e.g., a person, organization or domain). Membership in a particular class gives the entry the option of containing one set of attributes (optional attributes), and the obligation of containing another set of attributes (mandatory or required attributes). For example, an entry representing a person might belong to the class “person.” Membership in the “person” class would require the entry to contain the “sn” and “cn” attributes and allow the entry also to contain “userPassword,” “telephoneNumber” and other attributes.
The LDAP directory may be maintained by an LDAP directory server. The LDAP directory server may include a set of modules or services that are available to the server as plug-in modules. The plug-in modules each register with the LDAP directory server during a start up sequence. The registration process make the plug-in modules known to the LDAP directory server as well as the functions that are available from each plug-in. The functions may be referred to as ‘calls’ or ‘callbacks.’ For sake of clarity these functions are referred to herein as ‘callbacks. The order that callbacks are executed by an LDAP directory server are not guaranteed, but correspond to the order in which the respective plug-in modules are registered with the LDAP directory server. Thus, LDAP operations that utilize plug-in callbacks cannot rely on the order of their execution and such operations must be utilized or programmed in accordance with this limitation to ensure data coherency.